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METHOD AND APPARATUS FOR 
PERIODICALLY REMOVING INVALID 
PUBLIC KEYS FROM A PUBLIC KEY SERVER 

1 5 Inventor: William F, Price III 



Related Application 

The application hereby claims priority under 35 U.S.C. § 1 19 to 
20 Provisional Patent Application No. 60/230,23 5 filed on September 1 , 2000. 

The subject matter of this application is related to the subject matter in a 
co-pending non-provisional application by the same inventor as the instant 
application and filed on the same day as the instant application entitled, " Method 
and Apparatus for Managing Public Keys Through a Server, " having serial 
25 number TO BE ASSIGNED, and filing date TO BE ASSIGNED (Attorney 
Docket No. NA00-13402). 



1 

Attorney Docket No. NA00-13801 Inventor: William F. Price III 

ARPC \MY DOCUMENTS\NETWORK ASSOC1ATES\NAOO-13801\NAOO-13801 APPLICATION DOC 



BACKGROUND 

Field of the Invention 

The present invention relates to the field of computer security. More 
5 specifically, the present invention relates to a method and an apparatus for 
managing public keys by using a server that stores associations between public 
keys and email addresses. 

Related Art 

1 0 The advent of computer networks has led to an explosion in the 

development of applications that facilitate rapid dissemination of information. In 
particular, electronic mail (email) is becoming the predominant method for 
communicating textual and other non-voice information. Using email, it is just as 
easy to send a message to a recipient on another continent as it is to send a 

1 5 message to a recipient within the same building. Furthermore, an email message 
typically takes only minutes to arrive, instead of the days it takes for conventional 
mail to snake its way along roads and through airports. 

One problem with email is that it is hard to ensure that sensitive 
information sent through email is kept confidential. This is because an email 

20 message can potentially traverse many different computer networks and many 
different computer systems before it arrives at its ultimate destination. An 
adversary can potentially intercept an email message at any of these intermediate 

points along the way. 

One way to remedy this problem is to "encrypt" sensitive data using an 
25 encryption key so that only someone who possesses a corresponding decryption 
key can decrypt the message. (Note that for commonly used symmetric 
encryption mechanisms the encryption key and the decryption key are the same 
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key.) A person sending sensitive data through email can encrypt the sensitive data 
using the encryption key before it is sent through email. At the other end, the 
recipient of the email can use the corresponding decryption key to decrypt the 
sensitive information. 
5 Managing encryption keys for the millions of users who can potentially 

send encrypted email message is a challenging task. Some existing key 
management systems operate by enrolling public keys for users with an "identity 
authority." An identity authority typically operates by verifying the identities of 
owners of public keys as well as keeping track of revoked public keys. 
1 0 However, existing systems have a number of shortcomings. The 

verification process is often cumbersome. It typically involves some type of 
manual check, such as making a telephone call, taking a fingerprint, or receiving 
personal information from an owner of a public key. Although such manual 
checks provide a measure of security, they are time-consuming and can be 
1 5 impractical to perform for a large number of users. 

Another shortcoming is that the key revocation process does not work 
well. Some existing systems make use of a "certificate revocation list" (CRL), 
which contains a listing of revoked certificates. Before using a public key, a client 
typically checks a locally stored copy of a CRL to verify that the public key has 
20 not been revoked. However, a locally stored copy of a CRL may be updated only 
occasionally (for example, once a week), which means the locally stored copy of 
the CRL may not be current. This can create problems. For example, an 
employee who leaves a company may continue to receive sensitive encrypted 
email messages until the locally stored copy of the CRL is updated. 
25 Furthermore, a CRL can grow very large over time as more and more 

certificates are revoked. In some cases, a CRL can contain millions of entries! 
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Hence, a locally stored copy of a CRL can require a large amount space to store, 
and can be cumbersome to update. 

What is needed is a method and apparatus for managing encryption keys 
that does not require a time-consuming manual check during the verification 
5 process, and that does not suffer from the shortcomings of using a CRL to keep 
track of revoked keys. 

SUMMARY 

One embodiment of the present invention provides a system for managing 

1 0 public keys through a server that stores associations between public keys and 
email addresses. This system operates by receiving a first message from a client 
containing a request for approval of a client public key along with the client 
public key. In response this request for approval, the system sends a second 
message to the client containing a request for identity confirmation that includes 

1 5 the client public key. If a third message is received from the client containing an 
affirmative response to the request for identity confirmation, the system stores an 
association between a client email address and the client public key in a database. 
This allows other clients to look up the client public key in the database. 
In one embodiment of the present invention, the system additionally 

20 receives a communication from a second client that includes the client email 

address. In response to this communication, the system performs a lookup in the 
database based on the client email address to determine if the client email address 
is associated with the client public key. If the lookup indicates that the client 
email address is associated with the client public key, the system sends a key 

25 identifier for the client public key from the server to the client. This key identifier 
allows the client to determine whether the client possesses the client public key. 
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In one embodiment of the present invention, the request for approval 
includes key reconstitution information that allows the client to decrypt to an 
encrypted client private key at the client if the client forgets a passphrase for 
decrypting the encrypted client private key. This key reconstitution information is 
5 stored in the database at the server. Note that a "passphrase" is a generalization of 
a password that can potentially contain an entire phrase instead of a single 
password. 

In one embodiment of the present invention, the system decrypts the 
request for approval using a server private key, and then uses the client public key 
10 to verify that the request for approval is signed by a corresponding client private 
key. 

In one embodiment of the present invention, prior to sending the second 
message, the system determines if the database already contains a prior client 
public key associated with the client email address. If so, the system includes the 
15 prior client public key in the request for identity confirmation sent to the client. 
This enables the client to subsequently indicate that the server should replace the 
prior client public key with the client public key. 

In one embodiment of the present invention, the system additionally 
receives a request at the server to remove the client public key from the database. 
20 If this request is signed with a corresponding client private key, the system 
removes the client public key from the database. 

In one embodiment of the present invention, the database contains at most 
one key for each email address, 

In one embodiment of the present invention, the database contains at most 
25 one email address for each key. 

In one embodiment of the present invention, the system periodically sends 
a verification request from the server to the client email address asking if the 
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client public key remains valid. If an affirmative response to the verification 
request is not received, the system removes the client public key from the 
database. 

One embodiment of the present invention provides a system for managing 
public keys through a server that stores associations between public keys and 
email addresses. This system operates by receiving a client public key from a 
client, and then storing the client public key in a database at the server. The 
system then allows other clients to lookup the client public key in the database. 
The system also periodically sends a verification request from the server to the 
client asking if the client public key remains valid. If an affirmative response to 
the verification request is not received, the system removes the client public key 

from the database. 

In one embodiment of the present invention, the system stores the client 
public key in the database by signing the client public key using a server private 
key, and then storing the signed client public key in the database. 

In one embodiment of the present invention, the client public key is 
removed from the database only if an affirmative response is not received after 
sending multiple verification requests at different times. 

Note that the present invention facilitates automated identity confirmation 
without requiring a time-consuming manual check during the verification process. 
Furthermore, the present invention does not rely on locally stored key 
management information, which can potentially be outdated, and does not suffer 
from having to maintain a lengthy revocation list. 

BRIEF DESCRIPTION OF THE FIGURES 

FIG. 1 illustrates a distributed computer system in accordance with an 
embodiment of the present invention. 
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FIG. 2 illustrates messages sent during the key enrollment process in 
accordance with an embodiment of the present invention. 

FIG. 3 is a flow chart of the key enrollment process in accordance with an 
embodiment of the present invention. 
5 FIG. 4 is a flow chart of a client-initiated key removal process in 

accordance with an embodiment of the present invention. 

FIG. 5 is a flow chart of the key lookup process in accordance with an 
embodiment of the present invention. 

FIG. 6 is a flow chart of a server-initiated key removal process in 
1 0 accordance with an embodiment of the present invention. 

DETAILED DESCRIPTION 

The following description is presented to enable any person skilled in the 
art to make and use the invention, and is provided in the context of a particular 

1 5 application and its requirements. Various modifications to the disclosed 

embodiments will be readily apparent to those skilled in the art, and the general 
principles defined herein may be applied to other embodiments and applications 
without departing from the spirit and scope of the present invention. Thus, the 
present invention is not intended to be limited to the embodiments shown, but is 

20 to be accorded the widest scope consistent with the principles and features 
disclosed herein. 

The data structures and code described in this detailed description are 
typically stored on a computer readable storage medium, which may be any device 
or medium that can store code and/or data for use by a computer system. This 
25 includes, but is not limited to, magnetic and optical storage devices such as disk 
drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or 
digital video discs), and computer instruction signals embodied in a transmission 
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medium (with or without a carrier wave upon which the signals are modulated). 
For example, the transmission medium may include a communications network, 
such as the Internet. 

5 Networked Computer System 

FIG. 1 illustrates a networked computer system 100 in accordance with an 
embodiment of the present invention. Networked computer system 100 includes 
clients 108 and 118, which are coupled to server 120 through network 110. 
Clients 108 and 1 18 can generally include any type of computer system, including, 

1 0 but not limited to, a computer system based upon a microprocessor, a mainframe 
processor, a device controller, and a computational engine within an appliance. In 
the embodiment illustrated in FIG. 1, client 108 contains private key 104 and 
public key 106, which collectively form a private key-public key pair in such a 
way that a message to be encrypted using public key 106 and decrypted using 

1 5 private key 1 04. Note that private key 1 04 cannot be deduced from public key 
106 in a tractable amount of computational time. Similarly, client 118 contains 
private key 1 14 and public key 1 16, and server 120 includes private key 124 and 
public key 126. 

Network 1 10 can include any type of wire or wireless communication 
20 channel capable of coupling together client 1 08, client 1 1 8 and server 1 20. This 
includes, but is not limited to, a local area network, a wide area network, or a 
combination of networks. In one embodiment of the present invention, network 

110 includes the Internet. 

Server 120 can include any node on a computer network including a 
25 mechanism for servicing requests from clients 1 08 and 1 1 8 for computational 
and/or data storage resources. In the embodiment of the present invention 
illustrated in FIG. 1, server 120 processes requests to enroll keys in database 122 
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and to lookup keys in database 122. Database 122 can include any type of storage 
system that is capable of storing data for server 120. In one embodiment of the 
present invention, database 122 stores associations between email addresses and 
public keys. Also note that in one embodiment of the present invention database 
5 122 operates in conformance with the lightweight directory access protocol 
(LDAP). 

Key Enrollment Process 

FIG. 2 illustrates messages sent between client 108 and server 120 during 

10 the key enrollment process in accordance with an embodiment of the present 
invention. In order to enroll a public key, client 108 sends a message to server 
120 containing a request for approval 202. Request for approval 202 contains a 
message type field 203, which identifies the type of message. In this case, 
message type field 203 specifies that the message is a "request for approval." 

15 Request for approval 202 also includes a public key 106 belonging to client 108. 
Note that client 108 holds a corresponding private key 104. 

Request for approval 202 optionally contains key reconstitution information 
204, which can be used to decrypt private key 104 if user 101 forgets the passphrase 
that was used to encrypt private key 104. For example, this key reconstitution 

20 information 204 may allow user 101 to decrypt private key 104 by remembering 
answers to three of five questions, such as "what is your mother's maiden name?", 
or "what was your first dog's name?". This key reconstitution information is 
discussed in more detail in a pending U.S. patent application entitled, "Method and 
Apparatus for Reconstituting an Encryption Key Based on Multiple User Responses," 

25 by inventor William F. Price III, Serial No. 09/429,217, filed October 28, 1999. This 
application is hereby incorporated by reference to describe the key reconstitution 
process, 
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In one embodiment of the present invention, request for approval 202 is 
encrypted with public key 126 belonging to server 120, so that request for 
approval 202 can only be decrypted using corresponding private key 124, which is 
held by server 120. Request for approval 202 is also signed with private key 104 

5 belonging to client 1 08. This enables server 120 to use corresponding public key 
106 to verify that client 108 signed request for approval 202. 

Upon receiving request for approval 202, server 120 sends a message to 
the email address of client 108. This message includes a request for ID 
confirmation 206. Request for ID confirmation 206 contains a message type field 

1 0 207, which specifies that the message is a "request for ID confirmation." Request 
for ID confirmation 206 also contains public key 106, as well as existence flag 
208 and possibly an old public key 210. If old public key 210 already exists for 
client 108 in database 122, server 120 sets existence flag 208 to TRUE, and 
includes old public key 210 in request for ID confirmation 206. 

1 5 In one embodiment of the present invention, request for ID confirmation 

206 is encrypted with public key 106 belonging to client 108, so that request for 
ID confirmation 206 can only be decrypted using corresponding private key 104, 
which is held by client 108. Request for ID confirmation 206 is also signed with 
private key 124 belonging to server 120. This enables client 108 to use 

20 corresponding public key 126 to verify that server 120 signed request for ID 
confirmation 206. 

Upon receiving request for ID confirmation 206, client 108 sends a 
message to server 120, which includes response to ID confirmation 212. 
Response to ID confirmation 212 contains a message type field 213, which 

25 specifies that the message is a "response to ID confirmation." Response to ID 
confirmation 212 also includes replacement flag 214 and public key 106. 
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Replacement flag 214 is set to TRUE if client 108 would like to replace old public 
key 210 with new public key 106. 

In one embodiment of the present invention, response to ID confirmation 
212 is encrypted with public key 126 belonging to server 120, so that request for 
5 ID confirmation 206 can only be decrypted using corresponding private key 1 24, 
which is held by server 120. Request for ID confirmation 206 is also signed with 
private key 104 belonging to client 108. This enables server 120 to use 
corresponding public key 106 to verify that client 108 signed response to ID 
confirmation 212. 

1 0 Note that in one embodiment of the present invention, messages 202, 206 

and 212 are email messages. However, note that it is sufficient for only message 
206 from server 120 to client 108 to be an email message, so that server 120 can 
verify that the email address of client 108 is associated with public key 106. 

FIG. 3 is a flow chart of the key enrollment process in accordance with an 

1 5 embodiment of the present invention. User 1 0 1 first enters a name, an email 

address and a passphrase into client 108 (step 302). User 101 can optionally enter 
five questions and five responses to create key reconstitution information 204 as is 
discussed above with reference to FIG. 2 (step 304). Next, client 108 generates a 
key pair including private key 104 and public key 106 (step 306). Client 108 then 

20 constructs request for approval 202, as is described above with reference to FIG. 
2, and sends request for approval 202 to server 120 (step 308). 

Upon receiving request for approval 202 (step 310), server 120 decrypts 
request for approval 202 using server private key 124. Server 102 also uses public 
key 106 to verify that request for approval 202 has been signed by private key 104 

25 held by client 108. If request for approval 202 includes key reconstitution 

information 204, server 120 stores key reconstitution information 204 in database 
122 (step 311). 
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Server 120 also attempts to validate that public key 106 is associated with 
an email address of client 108. This is done by sending a message to the email 
address of client 108, and then receiving a response to the message. 

More specifically, server 120 constructs request for ID confirmation 206, 
as is described above with reference to FIG. 2, and sends request for ID 
confirmation 206 to client 108 (step 312). Note that if an old public key 210 is 
associated with the email address of client 108 in database 122, server 120 sets 
existence flag 208 to TRUE, and includes old public key 210 in request for ID 
confirmation 206. 

Upon receiving request for ID confirmation 206 (step 316), client 108 
decrypts request for ID confirmation using client private key 104. Client 108 also 
uses public key 126 to verify that request for ID confirmation 206 has been signed 
by private key 124 held by server 120. Next, client 108 constructs response to ID 
confirmation 212, as is described above with reference to FIG. 2, and sends 
response to ID confirmation 212 to server 120 (step 318). Note that if client 108 
would like to replace old public key 210 with new public key 106, client 108 sets 
replacement flag 214 within response to ID confirmation 212 to TRUE. 

Upon receiving response to ID confirmation 212, server 120 decrypts 
response to ID confirmation using server private key 124. Server 120 also uses 
public key 106 to verify that response to ID confirmation 212 has been signed by 
private key 104 held client 108. 

Next, server 120 stores an association between the email address of client 
108 and client public key 106 in database 122 (step 320). In one embodiment of 
the present invention, storing this association involves signing client public key 
106 using server private key 124, and then storing the signed client public key 106 
in database 122 indexed by the email address of client 108. 
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Note that in one embodiment of the present invention, database 122 
contains at most one public key for each email address. Furthermore, database 
122 contains at most one email address for each public key. 

Finally, after sending response to ID confirmation 212, client 108 
5 periodically polls server 120 to verify that new client public key 1 06 has been 
stored in database 122 (step 322). The enrollment process for public key 106 is 
now complete. 

Client-Initiated Key Removal Process 

1 0 FIG. 4 is a flow chart of a client-initiated key removal process in 

accordance with an embodiment of the present invention. During this process, 
client 108 receives a command from user 101 to unenroll client public key 106 
(step 402). In response this command, client 108 constructs a removal request 
and sends it the server 120 (step 404). Note that constructing this removal request 

15 involves signing the removal request with private key 104 belonging to client 108. 
Upon receiving the removal request (step 406), server 120 uses client 
public key 106 to verify that the request was validly signed with corresponding 
client private key 104. If the request is validly signed, server 120 removes client 
public key 106 from database 122. 

20 

Key Lookup Process 

FIG. 5 is a flow chart of the key lookup process in accordance with an 
embodiment of the present invention. Note that every time a client, such as client 
118, sends an encrypted email message, client 118 looks up the public keys of all 
25 recipients of the email message in database 122, so that client 1 1 8 can encrypt the 
email message to each of the recipients. Note that an encrypted email message is 
typically encrypted with a randomly generated session key, and this randomly 
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generated session key is typically encrypted with the public keys of each of the 
recipients to form a set of encrypted session keys. This set of encrypted session 
keys is sent along the with encrypted email message so that each of the recipients 
can decrypt the session key in order to decrypt the encrypted email message. 
5 In order to lookup a public key, client 1 1 8 sends a lookup request 

including an email address to database 122. Upon receiving the lookup request 
(step 502), database 122 decrypts and verifies the lookup request if necessary, and 
then performs a lookup using the email address (step 504). If the email address is 
associated with a public key 106 in database 122, database 122 returns an 

10 identifier for public key 106 (possibly signed and encrypted) to client 118 (step 
506). This identifier may be a hash (message digest) created from public key 106. 
Note that sending the identifier can be easier than sending the public key, because 
this identifier is smaller than the public key. However, note that if client 1 1 8 does 
not possess a local copy of public key 106, database 122 eventually sends public 

15 key 106 to client 118. 

Also note that in one embodiment of the present invention, 
communications between client 1 18 and database 122 involve fast LDAP 
communications instead of slower email messages. This makes it practical to 
perform lookups each time an encrypted email message is sent. 

20 In one embodiment of the present invention, in order to reduce the number 

of lookups, the system does not perform lookups into database 122 every time an 
encrypted email message is sent, but instead uses locally stored public keys for the 
message recipients. These locally stored public keys are periodically updated by 
performing lookups into database 122. 

25 
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Server-Initiated Key Removal Process 

FIG. 6 is a flow chart of a server-initiated key removal process in 
accordance with an embodiment of the present invention. In this embodiment, 
server 120, periodically verifies that each public key within database 122 remains 
5 valid. If a given key is not valid, it is removed from database 122. 

More specifically, for each public key stored in database 122, server 102 
sends a verification request to the associated email address (step 602). This 
verification request includes the client public key 106, and is possibly encrypted 
and signed by server 120. 
10 If an affirmative response is not received to the verification request, server 

120 removes client public key 106 from database 122 (step 604). 

For example, each client public key can be verified once every six months, 
and the verification request can be resent to client 108 every week for a month 
before removing public key 106 from database 122 for lack of response. 
1 5 Note that the above-described process removes public keys belonging to 

users who lose access the their email account, or users who die. Moreover, the 
above-described process solves the problem of users not being able to remove 
their public keys if they forget their password. 

The foregoing descriptions of embodiments of the present invention have 
20 been presented for purposes of illustration and description only. They are not 

intended to be exhaustive or to limit the present invention to the forms disclosed. 
Accordingly, many modifications and variations will be apparent to practitioners 
skilled in the art. Additionally, the above disclosure is not intended to limit the 
present invention. The scope of the present invention is defined by the appended 
25 claims. 
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What Is Claimed Is: 



1 LA method for managing public keys through a server, comprising; 

2 receiving a client public key from a client at the server; 

3 storing the client public key in a database at the server; 

4 allowing other clients to lookup the client public key in the database; 

5 periodically sending a verification request from the server to the client 

6 asking if the client public key remains valid; and 

7 if an affirmative response to the verification request is not received, 

8 removing the client public key from the database. 

1 2. The method of claim 1, wherein storing the client public key in the 

2 database involves: 

3 signing the client public key using a server private key; and 

4 storing the signed client public key in the database. 

1 3. The method of claim 1, further comprising: 

2 receiving a request at the server to remove the client public key from the 

3 database; 

4 if the request is signed with a corresponding client private key, removing 

5 the client public key from the database. 

1 4. The method of claim 1, wherein the client public key is removed 

2 from the database only if an affirmative response is not received after sending 

3 multiple verification requests at different times. 
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1 5. The method of claim 1, wherein storing the client public key in the 

2 database at the server involves: 

3 attempting to validate an association between a client email address and 

4 the client public key; and 

5 if the association is successfully validated, storing the association in the 

6 database. 

1 6. The method of claim 5, wherein the database contains at most one 

2 key for each email address. 

1 7. The method of claim 5, wherein the database contains at most one 

2 email address for each key. 

1 8. A computer-readable storage medium storing instructions that 

2 when executed by a computer cause the computer to perform a method for 

3 managing public keys through a server, the method comprising: 

4 receiving a client public key from a client at the server; 

5 storing the client public key in a database at the server; 

6 allowing other clients to lookup the client public key in the database; 

7 periodically sending a verification request from the server to the client 

8 asking if the client public key remains valid; and 

9 if an affirmative response to the verification request is not received, 
1 0 removing the client public key from the database. 

1 9. The computer-readable storage medium of claim 8, wherein storing 

2 the client public key in the database involves: 

3 signing the client public key using a server private key; and 

17 

Attorney Docket No. NAOO-13801 inventor: William F. Price III 

ARPUPORSCHE\MY DOCUMENTS\NETWORK ASSOCIATES\NA00-1380i\NA00-1380t APPLICATION DOC 



1 



storing the signed client public key in the database. 



1 10. The computer-readable storage medium of claim 8 5 wherein the 

2 method further comprises: 

3 receiving a request at the server to remove the client public key from the 

4 database; 

5 if the request is signed with a corresponding client private key, removing 

6 the client public key from the database. 

1 11. The computer-readable storage medium of claim 8, wherein the 

2 client public key is removed from the database only if an affirmative response is 

3 not received after sending multiple verification requests at different times. 

1 12. The computer-readable storage medium of claim 8, wherein storing 

2 the client public key in the database at the server involves: 

3 attempting to validate an association between a client email address and 

4 the client public key; and 

5 if the association is successfully validated, storing the association in the 

6 database. 

1 13. The computer-readable storage medium of claim 12, wherein the 

2 database contains at most one key for each email address. 

1 14. The computer-readable storage medium of claim 12, wherein the 

2 database contains at most one email address for each key. 
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1 1 5. An apparatus that facilitates managing public keys through a 

2 server, comprising: 

3 a storing mechanism that is configured to store a client public key in a 

4 database at the server; 

5 a lookup mechanism that is configured to allow other clients to lookup the 

6 client public key in the database; and 

7 a key removal mechanism that is configured to, 

8 send a verification request from the server to the client 

9 asking if the client public key remains valid, and to 

10 remove the client public key from the database, if an 

1 1 affirmative response to the verification request is not received. 

1 1 6. The apparatus of claim 15, wherein the storing mechanism is 

2 configured to: 

3 sign the client public key using a server private key; and to 

4 store the signed client public key in the database. 

1 17. The apparatus of claim 15, wherein the key removal mechanism is 

2 additionally configured to: 

3 receive a request to remove the client public key from the database; and to 

4 remove the client public key from the database if the request is signed with 

5 a corresponding client private key. 

1 18. The apparatus of claim 15, wherein the key removal mechanism is 

2 configured to remove the client public key from the database only if an affirmative 

3 response is not received after sending multiple verification requests to the client at 

4 different times. 
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1 19. The apparatus of claim 15, wherein the storing mechanism is 

2 configured to: 

3 attempt to validate an association between a client email address and the 

4 client public key; and to 

5 storing the association in the database, if the association is successfully 

6 validated. 



1 20. The apparatus of claim 1 9, wherein the database contains at most 

2 one key for each email address. 

1 21 . The apparatus of claim 19, wherein the database contains at most 

2 one email address for each key. 
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METHOD AND APPARATUS FOR 
PERIODICALLY REMOVING INVALID 
PUBLIC KEYS FROM A PUBLIC KEY SERVER 

ABSTRACT 

One embodiment of the present invention provides a system for managing 
public keys through a server that stores associations between public keys and 
email addresses. This system operates by receiving a client public key from a 
client, and then storing the client public key in a database at the server. The 
system then allows other clients to lookup the client public key in the database. 
The system also periodically sends a verification request from the server to the 
client asking if the client public key remains valid. If an affirmative response to 
the verification request is not received, the system removes the client public key 
from the database. 
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